Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/answers/comp/cell-relay-faq

Internet Message Format | 1993-12-02 | 48KB

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news.kei.com!eff!news.umbc.edu!haven.umd.edu!umd5.umd.edu!not-for-mail
From: [e-mail] (Carl Symborski)
Newsgroups: comp.dcom.cell-relay,comp.answers,news.answers
Subject: comp.dcom.cell-relay FAQ: ATM, SMDS, and related technologies
Followup-To: comp.dcom.cell-relay
Date: 1 Dec 1993 02:37:00 -0500
Organization: University of Maryland, College Park
Lines: 1107
Sender: [e-mail]
Approved: [e-mail]
Message-ID: <2dhhis$[e-mail]>
NNTP-Posting-Host: macbeth.umd.edu
Summary: General information and answers to questions related to or seen
         in the comp.dcom.cell-relay group.
Keywords: cell-relay, ATM, SMDS, communications
Xref: senator-bedfellow.mit.edu comp.dcom.cell-relay:2359 comp.answers:2860 news.answers:15247

Archive-name: cell-relay-faq
Last-modified: 1993/11/30

FAQ-Maintainer: Carl Symborski ([e-mail])

This article mostly contains general information but also answers to some
Frequently Asked Questions (FAQ) which are related to or have been seen in
comp.dcom.cell-relay.  It is posted to provide information of general
interest to both new and experienced readers.

This list includes answers to questions, which are loosely grouped into
categories.  Questions marked with a "+" are new in this issue; those with
significant changes of content since the last issue are marked by "*":

 A)  TOPIC: COMP.DCOM.CELL-RELAY BASIC INFORMATION
  A1)   What is the CELL-RELAY group?
  A2) * What is the archive site for this group?
  A3) * Is there a parallel mailing list for this group?
  A4) * What other mailing lists are related to ATM?
 B)  TOPIC: INDUSTRY FORUMS AND VENDOR INFORMATION
  B1) * How can I contact the ATM Forum?
  B2) * What vendors are working on ATM technology?
  B3)   What vendors are working on ATM hardware/chips?
  B4)   What vendors are selling ATM test equipment?
  B5)   Are there any ATM interface boards for PCs?
  B6)   Where are the ATM Forum's FTP sites and mailing lists?
 C)  TOPIC: ATM REFERENCES
  C1)   What are some good getting started ATM references?
  C2)   Where/What is the "Network Compatible ATM for LANs" document?
  C3)   Where are hosts with ATM related information?
  C4) * How can I get the ATM Forum's Interface Specifications?
  C5) * List of ITU-TS Recommendations concerning ATM.
  C6) * Internet drafts from IETF working groups.
  C7) * ATM Tutorials.
  C8)   Contact information for ANSI T1S1 specifications.
  C9)   Internet RFCs.
  C10)+ ATM and Related Acronyms.
 D)  TOPIC: ATM TECHNOLOGY QUESTIONS
  D1)   What are the various ATM Access layers?
  D2)   Are ATM cells delivered in order?
  D3)   What do people mean by the term "traffic shaping"?
  D4)   What is happening with signalling standards for ATM?
  D5)   What is VPI and VCI?
  D6)   Why both VPI *and* VCI?
  D7)   How come an ATM cell is 53 bytes anyway?
  D8)   How does AAL5 work?
  D9)   What are the diffferences between Q.93B and Q.931?
 E)  TOPIC: ATM VS. XYZ TECHNOLOGY
  E1)   How does ATM differ from SMDS?
 F)+ TOPIC: FREELY AVAILABLE REFERENCE IMPLEMENTATIONS
  F1) + What and where is VINCE?

If you have suggestions or corrections for any of these answers or any
additional information, please send them directly to [e-mail];
the information will be included in the next revision (or possibly the one
after that).

This posting is intended to be distributed every few months. New versions
are archived along with other comp.dcom.cell-relay traffic on
cell-relay.indiana.edu.  See subject A2 for instructions to access the
archive.

The information contained herein has been gathered from a variety of sources.
Most derived from a consensus of postings on the group.  A listing of
contributors so far can be found at the end of the FAQ text. If you would
like to claim responsibility for a particular item, please let me know.

Enjoy!

Carl Symborski                              Alguien tiene que escuchar
[e-mail]                           Oye este canto que ya va a empezar


-----------------------------------------------------------------------------
TOPIC:     A)   TOPIC: COMP.DCOM.CELL-RELAY BASIC INFORMATION
-----------------------------------------------------------------------------
SUBJECT:  A1)   What is the CELL-RELAY group?

    The purpose of this group is to provide a forum for the submission
of articles and inquiries dealing with networks using Cell Relay as a
transport; including local, metropolitan, and wide area networks.  The
name cell-relay was chosen as a compromise over objections to the name
"ATM" during the creation of this group.  The acronym ATM in the context of
this group stands for Asynchronous Transfer Mode, not Automatic Teller
Machines or Adobe Type Manager.  The term "cell" in cell-relay is taken to
mean a small, fixed sized, information bearing unit that provides the
foundation for transport and multiplexing of user traffic.  This topic
area is not related to cellular phones or intra-cellular organisms.


SUBJECT:  A2) * What is the archive site for this group?

    The archives for comp.dcom.cell-relay are available via anonymous
ftp to cell-relay.indiana.edu as:

    /pub/cell-relay/archive/YY-MM.mbox

where YY=year and MM=month.  There are available in both
compressed and normal formats.


SUBJECT:  A3) * Is there a parallel mailing list for this group?

    A direct mailing list has been setup which is a mirror of the USEnet
newsgroup comp.dcom.cell-relay. To send mail TO the list, send it to:

    [e-mail]

To un/subscribe, or send other notes to the list management, please use:

        [e-mail]


SUBJECT:  A4) * What other mailing lists are related to ATM?

    There are several lists described below.  One is for an IETF group
working on the issue of IP over ATM.  This work is on going and primarily
focused on that task.  General ATM questions and blue-skying are inappropriate
and discouraged by the members on the list.  To send mail TO the list, send
it to:

    [e-mail]

To un/subscribe, or send other notes to the list management, use the address:

    [e-mail]

    Related to cell-relay technology is the Distributed Queueing mailing
list.  The distributed queueing list is intended for discussion about protocol
design, variants, extensions, associated with the use of DQ for arbitrating
access to cells in shared-medium cell-relay networks.  To send mail TO the
list, sent it to:

    [e-mail]

To un/subscribe, or send other notes to the list management, use the address:

    [e-mail]

        Another IETF working group is working on the issue of general routing
over networks (large clouds).  As with the IP over ATM list it is best to
subscribe with the intention to just "listen in".  To un/subscribe to this
list use the address:

        [e-mail]

    Also of possible interest is the mailing list for the SMDS special
interest group (SIG) Technical Committee.  To send mail TO the list, send
it to:

    [e-mail]

To un/subscribe, or send other notes to the list management, use the address:

    [e-mail]


-----------------------------------------------------------------------------
TOPIC:     B)   INDUSTRY FORUMS AND VENDOR INFORMATION
-----------------------------------------------------------------------------
SUBJECT:  B1) * How can I contact the ATM Forum?

    Similar to the Frame Relay Forum, the ATM Forum is an open public
forum with over 300 contributing and auditing companies.  Membership
includes many international companies.  Some companies also
participate in ANSI T1S1 and other standards bodies.  Audit membership of the
Forum is $1500/year.  Those interested in joining the forum or needing
additional information should contact:

The ATM Forum
480 San Antonio Road, Suite 100
Mountain View, CA 94040-1219  U.S.A
Tel [phone]
Fax [phone]
Email [e-mail]

The ATM Forum also has a FAX-On-Demand service.  Using this it is possible to
get instructions, order forms, membership applications, etc.  Just dial
[phone] from a FAX phone and follow the instructions.


SUBJECT:  B2) * What vendors are working on ATM technology?

    It is tough to get a number on this.  Increasingly there are companies
with hardware they can demonstrate.  More who have made product announcements.
Many more who have stated product intentions.  Some are building big
central office switches, others smaller ones for the LAN market.  Workstation
vendors are working on ATM interface boards.  Chip companies are working on
ATM chip sets, etc.  There are now software vendors advertizing protocol
software stacks (Q.93B, etc.) suitable for inclusion in ATM products.

Previously (in 1992) there was an attempt here to list most of the major
players in the ATM arena.  This was possible in 1992.  At this time
*everyone* is doing something or paying lip service to ATM.  It is simply
not practical to keep a fair and accurate list here in this FAQ.

Some postings on the cell-relay list (Fall 1993) attempted to again list the
current vendors developing and/or selling equipment in this technology area.
As predicted, these partial lists exceeded 40 vendors!


SUBJECT:  B3)   What vendors are working on ATM hardware/chips?

        As with ATM technology vendors, the number of companies developing
board level components is growing and soon will be hard to track.

For starters, there is a group in North America working on low-cost
SONET-based ATM physical layer chips for local nets using optics and twisted
pair interfaces.  This group is called the Saturn Development Group, and
consists of PMC-Sierra, Sun Microsystems, Ungermann-Bass, Bell-Northern
Research, Interphase, Optical Data Systems, SynOptics Communications,
Themis Computer, BBN, MPR Tetltech, the University of
British Columbia, and maby others.  Contact PMC-Sierra for information:

        PMC-Sierra, Inc.
        8999 Nelson Way
        Burnaby, BC
        Canada V5A 4B5
        604-293-5755

Adaptive has designed an ATM/AAL chipset for use in equipment (computer,
workstation, router, etc.) which connects to an ATM network.  That chipset
is now licenced to two chip manufacturers, TransSwitch and National
Semiconductor.  The TransSwitch product is called SARA and consists of a
segmentation chip and reassembly chip.  Together they can form the basis of
an ATM/AAL controller which can process up to 8000 packets simultaneously
at speeds of up to 155.52 Mbit/s.  The chip set implements BISDN adaptation
layers AAL3/4 and AAL5 in addition to supporting constant bit rate
(CBR) traffic.  Presumably the National Semiconductor product is similar.

Fujitsu makes a 4 x 4 switch element chip set (MB86680).


SUBJECT:  B4)   What vendors are selling ATM test equipment?

         There exist already a number of vendors that hava ATM test equipment
available. To name a few:

1. ATM-100, Wandel & Goltermann
    Tel.: [phone]
    Fax.: [phone]

2. ATM Test Tool, Siemens AG
    Tel.: [phone]
                     7077
    Fax.: [phone]
    The Siemens tool is the same as the Wandel & Goltermann tool

3. HP 75000 Series 90 ATM Analyzer, contact your local Hewlett Packard sales
    office

4. HP Broadband Series protocol test system,
    IDACOM Telecom Division,
    Hewlett Packard (Canada) Ltd.
    Edmonton, Alberta
    Canada T6E 5R6
    Tel.: [phone]
          [phone]
    Fax.: [phone]

5. Alcatel 8643 ATM Traffic Generator Analyzer, and Alcatel 8640, Alcatel STR,
    Tel.: [phone]
    Fax.: [phone]
    or Alcatel Network Systems Inc., Richardson, TX
    Tel.: [phone]
    Fax.: [phone]

6. Adtech AX/3000 ATM Cell Data Generator, AX/3010 DS3 ATM Cell Data Generator
        1814 Algaroba St,
        Honolulu HI 96826
        Tel.: [phone]
        Fax.: [phone]

This list is provided for information purposes only.  There is no implied
claim that this list is correct or complete.



SUBJECT:  B5)   Are there any ATM interface boards for PCs?

        National Semiconductor has an ESIA ATM card (Vicksburg DP8300VK) which
will be available in November 1993.  NET will resell the board.  Also, at the
August 1993 Interop IBM was demonstrating their PS/2 based ATM cards.


SUBJECT:  B6)   Where are the ATM Forum's FTP sites and mailing lists?

        The ATM Forum is a members only organization.  Although an open public
forum (which means that anyone can join) only members have direct access to
Forum activities and documentation. There are *NO* FTP sites and *NO* open
e-mail lists.

        Note that the minimal entry to the Forum is as an Auditing Member.
Auditing Members are allowed access to the e-mail distribution lists to "audit"
all documentation but are NOT ALLOWED to make comments.  Please note that
auditing members are not allowed to attend Technical and Market Commitee
meetings, not allowed to vote on issues and not allowed to submit technical
contributions.  See subject B1 for ATM Forum membership information.


-----------------------------------------------------------------------------
TOPIC:     C)   ATM REFERENCES
-----------------------------------------------------------------------------
SUBJECT:  C1) * What are some good getting started ATM references?

    Generally it is impossible  to pick up any communications related
technical journal, conference, or trade publications and not find something
about ATM.  Most of what has been written in the 1985 through 1990 time frame
primarily deals with the application of ATM to Broadband ISDN.  These provide
the foundation on which other applications of ATM have been based and therefore
should not be over looked.

Without a doubt, if you are at all serious about learning ATM, the best
references are the series of specifications developed by the ATM Forum.
These are the:

    o ATM User-Network Interface Specification, Ver 3.0, September 10, 1993
    o The ATM Forum BISDN Inter Carrier Interface (B-ICI) Specification,
        Ver 1.0 August, 1993

The ATM Forum's DXI specification is also useful.  See subject C4 for
ways to obtain these documents.

Note that because of the pace of ATM standardization, reference books rapidly
become out-of-date.  Specifically, there have been major changes to the
specification of the AALs subsequent to the publication of these books and
articles.  However, the following references do offer a good base of
background information.  Note, see also subject C7 for ATM Tutorials.

--General:

"Data Communications Special Guide", IEEE Spectrum, 8/91, p.22.
   o Hi-level overview of high-speed lans, wans, bisdn, atm, with glossary
     and bibliography.

IEEE Communications Magazine, April 1992, VOL. 30, NO. 4
   o This is a special issue with six articles on gigabit networks technology.

"Cell Relay Switching", Data Communications, 9/91, p.58.
   o Looks at cell relay and switching in general, not just ATM.

Rainer Handel and Manfred Huber. "Integrated Broadband Networks: An
   Introduction to ATM-Based Networks". Addison-Wesley, 1991.
   ISBN 0-201-54444-X.


--ATM:

"Overview of ATM Networks: functions and procedures", Computer Communications,
   12/91, p.615.
   o Cell headers, bit definitions and the like. 33 References, including
     good list of CCITT recommendations.

"Broadband ISDN and Asynchronous Transfer Mode (ATM)", IEEE Communications,
   9/89.
   o Describes most of the jargon as well as the paradigm and unresolved
     issues.  One point to note is that the article is fairly old (1989) and
     some things have changed.  For example, the ATM cell headers described
   are no longer valid.

"Asynchronous Transfer Mode: Solution for Broadband ISDN", Martin de Prycker,
   Ellis Horwood, New York, 1991.  ISBN 0-13-053513-3
   o See Martin's more recent book below.

"Asynchronous Transfer Mode", Martin De Prycker, Ellis Horwood, New York
   1993, ISBN 0-13-178542-7.
   o Very readable general description of the technology and optimization.
     Even though its recent some of the details have changed AND the book
     is NOT long on details. Also, this is primarily an ITU-oriented
     (telecomm services) view of ATM, not an ATM Forum-oriented view (CPE), I
     believe.

"Gigabit Networking", Craig Partridge, Addison-Wesley, Reading MA,
   1993, ISBN 0-201-56333-9.
   o Very well written book.  Craig is the Editor of "IEEE Network" magazine.
     Topics: fiber optics, cell networking, ATM, Gbps packet schemes,
     applications, host interface, higher protocols, bandwidth management and
     performance, distributed systems, etc.


--SWITCH FABRICS:

These papers offer a fast jump start on ATM switch architectures, design
issues and tradeoffs.

H. Ahmadi and W. Denzel, "A Survey of Modern High-Performance Switching
   Techniques", IEEE J on Selected Areas in Comm, Vol. 7, No. 7, Sept 1989,
   p. 1091-1103

F. Tobagi, "Fast Packet Switch Architectures for Broad-band Integrated
   Services Digital Networks", Proceedings of IEEE, Vol. 78, No. 1, Jan. 1990
   p. 133-167

Joseph Y. Hui, "Switching and Traffic Theory for Integrated Broadband
   Networks", Kluwer Academic Publishers, 1991,  ISBN 0-7923-9061-X
   o A back to basics text book explaining core switching concepts like
     batcher/banyon, clos, min, buffering, etc.


Technical journals
==================
        IEEE Network
        IEEE Communications
        IEEE Journal on Selected Areas in Communications
        IEEE Transactions on Communications
        IEEE/ACM Transactions on Networking
        Computer Communication Review (by ACM SIGCOMM)
        Computer Communications
        Computer Networks and ISDN Systems
        IEICE Transactions on Communications
        Journal of High Speed Networks

Magazines
=========
        Communications Week
        Data Communications
        Open Systems Today


SUBJECT:  C2)   Where/What is the "Network Compatible ATM for Local Network
                Applications" document?

"Network Compatible ATM for Local Network Applications", V1.01, October 19,
1992.  A proposal for a 150 Mb ATM LAN from Apple, Bellcore, Sun and Xerox.
Available in standard postscript and compressed standard postscript from:

thumper.bellcore.com: /pub/nclatm/nclatm.ps
                      /pub/nclatm/nclatm.ps.Z
ftp.apple.com:        /pub/latm/nclatm.ps
                      /pub/latm/nclatm.ps.Z
parcftp.xerox.com:    /pub/latm/nclatm.ps
                      /pub/latm/nclatm.ps.Z


SUBJECT:  C3)   Where are hosts with ATM related information?

    Here's a list of sites that that seem to cater to the
ATM/broadband/real-time continuous-media crowd:

cc-hw.bbn.com                Rec_I_cls.ps, Rec_I_cls.hqx
icsi-ftp.Berkeley.EDU        Research, Continuous media
wuarchive.wustl.edu          Research, ATM Hardware
datanet.tele.fi              Standards drafts (see below)
nsco.network.com             HIPPI
gregorio.stanford.edu        IP Multicast
cell-relay.indiana.edu       cell-relay archives, etc. (see below)

If you have ftp access, ftp to cell-relay.indiana.edu as user anonymous and
look in /pub/cell-relay for:

        1) In /pub/cell-relay/bib
           A bibliography of ATM research.  This includes several to
           reference books and LOTS of citations.
        2) In /pub/cell-relay/docs
           Some papers on ATM-related topics, standards, etc.
        3) In /pub/cell-relay
           This FAQ list!
        4) In /pub/cell-relay/conferences
           A bunch of files describing upcoming conferences

(Special thanks to Allen Robel for hosting this list and archive.)

Additionally, there are some draft standards, RFCs, technical papers, etc.
on ATM available at datanet.tele.fi in the directory called /atm
The collection includes draft AAL5 CCITT standards.  This is a general good
place to look.


SUBJECT:  C4) * How can I get the ATM Forum's Interface Specifications?

    The ATM Forum has produced a document called the User-Network
Interface specification.  This document applies to both the "Private UNI"
between an ATM user and a private ATM switch, and also a "Public UNI" between
a private ATM switch or a user and the public network.  The specification
contains information on the ATM bearer services, physical level interface
options, local network management, traffic, and signalling for both the
private and public UNIs.

For those which are not ATM Forum members, hard copies will be available
for purchase at book stores and direct from Prentice Hall.  This specification
is due to be published by Prentice Hall on 12/15/93 and will cost $34.  It
can be backordered now.  To do this call 1-800-374-1200 and ask for the
following book:

Title:  ATM User-Network Interface Specification
Author: ATM Forum
ISBN:   0-132-25863-3

The ATM Forum's DXI and B-ICI specification can be ordered directly from the
ATM Forum.  Call the ATM Forum information line for ordering information
[phone].  See also subject B1.


SUBJECT:  C5) * List of ITU-TS recommendations concerning ATM

    This list is provided for informational purposes only.  No guarantee
as to its completeness or correctness.  Also, although they are not formally
published, many of the following recommendations have been substantially
updated since first published.

You can buy these on paper from the ITU:
    ITU
    Place des Nations
    CH-1211 Geneva 20
    Switzerland.
The fax number of the sales office is [phone].  They are also
available commercially from at least 2 sources in the U.S.:

    Information Gatekeepers in Boston, MA (1-800-323-1088)
    Phillipps Publishing  (1-800-OMNICOM)

Phillips usually has documents in stock & has fast delivery.

    =ITU-TS Recommendations Concerning ATM =

E.164      Numbering plan for the ISDN era                   11/91
G.707      Synchronous digital hierarchy bit rates           04/91
G.708      Network node interface for the synchronous        06/92
       digital hierarchy
G.709      Synchronous multiplexing structure                06/92
I.113      B-ISDN Vocabulary of Terms                        04/91
I.121R     Broadband Aspects Of ISDN                         04/91
I.150      B-ISDN asynchronous transfer mode functional      06/92
       characteristics
I.211      B-ISDN service aspects                            04/91
I.311      B-ISDN General Network aspects                    06/92
I.321      B-ISDN protocol reference model and its           04/91
       application
I.327      B-ISDN functional architecture                    04/91
I.361      B-ISDN ATM layer specification                    06/92
I.362      B-ISDN ATM  adaptation layer (AAL) functional     04/91
       description
I.363      B-ISDN ATM adaptation layer (AAL) specification   06/92
I.413      B-ISDN user-network interface                     04/91
I.432      B-ISDN user-network interface - Physical layer    06/92
       specification
I.610      OAM principles of the B-ISDN access               06/92



Also, there are draft recommendations yet to be published (or I am just not
sure of their status):

I.35B   BISDN ATM Layer Cell Transfer Performance, 1992
I.363   Temp Doc 10 (XVIII) 'AAL Type 5 , Draft Recommendation text for
                             ssection 6 of I.363"  06/93
I.364    Temp Doc 58 (XVIII) 'Support of Broadband Connectionless Data
                             Service on B-ISDN'  06/92
I.365.1 Frame Relaying Service Specific Convergence Sublayer (FR-SSCS) 06/93
I.371    Temp Doc 64 (XVIII) 'Traffic Control and Congestion Control in
                             B-ISDN'  05/92
I.555   Frame Relaying Bearer Service Interworking  06/93
Q.93B   B-ISDN User-Network Interface Layer 3 Specification for Basic
        Call/Bearer Control,  04/93
Q.931   ISDN user-network interface layer 3 specification for basic
        call control  05/92
Q.933   Digital Subscriber Signalling Systems No. 1 (DSS 1) Signalling
        Specification for Frame Mode Basic Call Control  05/92
G.804   Which describes the mapping of ATM cells into PDH links at 1.544,
        2.048, 6.312, 34.368, 44.736, 97.728, 139.264 Mb/s (Jan 1993)



SUBJECT:  C6) * Internet drafts from IETF working groups.

        Various work items of the IP over Asynchronous Transfer Mode Working
group and other working groups of the IETF currently available include:

        draft-ietf-atm-address-resolve-00.txt
        draft-ietf-atm-address-translation-00.txt
        draft-ietf-atm-classic-ip-05.txt
        draft-ietf-atm-mtu-05.txt
        draft-heinanen-nhrp-01.txt
        draft-ietf-iplpdn-directed_arp-01.txt
        draft-ietf-atm-multipro-06.txt
        draft-ietf-atm-nmba-01.txt
        draft-ietf-rolc-nhrp-00.txt
        draft-ietf-atommib-atm-01.txt

Internet-Drafts are available by anonymous FTP.  Internet-Drafts directories
are located at:

     o  East Coast (US) ds.internic.net (198.49.45.10)
     o  Pacific Rim     munnari.oz.au (128.250.1.21)
     o  Europe          nic.nordu.net (192.36.148.17)

Internet-Drafts are also available by mail.  Send a message to:
[e-mail].  In the body specify the filename requested.  For
example type: "SEND draft-ietf-atm-multipro-06.txt".


SUBJECT:  C7) * ATM Tutorials.

        The following ATM tutorials are available via anonymous FTP.

    Machine:  ftp.magic.net
    Path:     pub/magic
    File:     ip-atm.ps   (PostScript)
              ip-atm.ps.Z (Compressed PostScript)
The focus of this paper is running IP over ATM, but there is an extensive
tutorial on ATM, followed by discussion IP over ATM networks.


    Machine:  datanet.tele.fi
    Path:     atm/articles
    File:     atm-intro.txt
This paper is also a good starting point.

And a the following publically available paper is a good start:
"The Asynchronous Trnasfer Mode: A Tutorial" by Jean-Yves Le Boudec
in Computer Networks and ISDN, Vol 24, No 4, May 1992, pp 279-309

Additionally there are reasonable tutorials available from three commercial
communications companies.  Specifically:

1. "ATM In Private Networking", Anthony Alles, Hughes LAN Systems, Spring 1993
   This was handed out at the Spring 1993 Interop for free.  Contact
   Hughes LAN Systems, Inc., 1225 Charleston Road, Mountain View, CA 94043.
   Phone: [phone]  Fax: [phone]  (Note no guarentee that they
   will send out a copy.)

2. "Asynchronous Transfer Mode: Bandwidth for the Future", Jim Lane, Telco
   Systems, 1992.  To order a free copy simply call 1-800-447-2537

3. "Broadband Testing Technologies", (a HP Seminar Handbook), Hewlett-
   Packard Company, February 1993, Document number 5091-6902E
   Call your local HP sales office and or contact the HP IDACOM Test
   division.  The inside cover claims this document costs $10.


SUBJECT:  C8)   Contact information for ANSI T1S1 specifications.

        These documents can be obtained directly from the Secretariat for
the ANSI T1 Telecommunications committee.

        Exchange Carriers Standard Association
        1200 G. Street N.W.  Suite 500
        Washington, D.C. 20005

All orders and requests for quotations on prices must be in writing.  Their
FAX number is: [phone]


SUBJECT:  C9)   Internet RFCs

        The following RFCs are available related to cell-relay technology.

        RFC 1483: Multiprotocol Encapsulation over ATM Adaptation Layer 5


SUBJECT:  C10) + ATM and Related Acronyms

        These are a few acronyms which tend to appear in postings, RFCs,
standards and other text related to the cell-relay topic area.

AAL     ATM Adaptation Layer
ATM     Asynchronous Transfer Mode
BISDN   Broadband Integrated Services Digital Network
CBR     Constant Bit Rate
CLP     Cell Loss Priority (as in CLP bit)
CPCS    Common Part Convergence Sublayer
CS      Convergence Sublayer (as in CS_PDU)
DXI     Data Exchange Interface (as in ATM DXI)
GFC     Generic Flow Control
HEC     Header Error Control
ILMI    Interim Local Management Interface
NLPID   Network Layer Protocol ID
NNI     Network Node Interface
NSAP    Network Layer Service Access Point
PDU     Protocol Data Unit
PLCP    Physical Layer Convergence Procedure
PTI     Payload Type Identifer
PVC     Permanent Virtual Circuit
QOS     Quality of Service
SAR     Segmentation and Reassembly (as in SAR_PDU)
SDH     Synchronous Digital Hierarchy
SDU     Service Data Unit (as in AAL_SDU)
SIR     Sustained Information Rate
SMDS    Switched Multi-Megabit Data Service
SNAP    SubNetwork Attachment Point (see IEEE 802.1a)
SNI     Subscriber Network Interface
SSCS    Service Specific Convergence Sublayer
SSCOP   Service Specific Connection Oriented Protocol
SVC     Switched Virtual Circuit
UNI     User to Network Interface
VBR     Variable Bit Rate
VC      Virtual Channel (not circuit)
VCC     Virtual Channel Connection
VCI     Virtual Channel Identifier
VP      Virtual Path
VPC     Virtual Path Connection


Here are a few five dollar words which sometime come arise in this topic area.

Plesiochronous: Signals which are arbitrarily close in frequency to some
   defined precision.  They are not sourced from the same clock and so, over
   the long term, will be skewed from each other.  Their relative closeness of
   allows a switch to cross connect, switch, or in some way processs
   them.  That same inaccuracy of timing will force a switch, over time, to
   repeat or delete frames (called frame slips) in order to handle buffer
   underflow or overflow.

Synchronous: Signals that are sourced from the same timing reference.  These
   have the same frequency. (Contrast with Plesiochronous signals)

Asynchronous: Signals that are sourced from independent clocks.  These signals
   generally have no relation to each other and so have different frequencies
   and phase relationships.  (Contrast with Plesiochronous signals)

Isochronous: Signals which are dependant on some uniform timing or carry
   their own timing information embedded as part of the signal.


-----------------------------------------------------------------------------
TOPIC:     D)   ATM TECHNOLOGY QUESTIONS
-----------------------------------------------------------------------------
SUBJECT:  D1)   What are the various ATM Adaptation layers?

    In order for ATM to support many kinds of services with different
traffic characteristics and system requirements, it is necessary to adapt
the different classes of applications to the ATM layer.  This function is
performed by the AAL, which is service-dependent.  Four types of AAL were
originally recommended by CCITT.  Two of these have now been merged
into one.  Also, within the past year a fifth type of AAL has been proposed.

    Briefly the four ATM adaptation layers (AAL) have/are being defined:

AAL1 - Supports connection-oriented services that require constant bit rates
       and have specific timing and delay requirements.  Example are constant
       bit rate services like DS1 or DS3 transport.

AAL2 - Supports connection-oriented services that do not require constant
       bit rates.  In other words, variable bit rate applications like
       some video schemes.

AAL3/4 - This AAL is intended for both connectionless and connection oriented
       variable bit rate services.  Originally two distinct adaptation layers
       AAL3 and 4, they have been merged into a single AAL which name is
       AAL3/4 for historical reasons.

AAL5 - Supports connection-oriented variable bit rate data services.  It is
       a substantially lean AAL compaired with AAL3/4 at the expense of
       error recovery and built in retransmission.  This tradeoff provides
       a smaller bandwidth overhead, simpler processing requirements, and
       reduced implementation complexity.  Some organizations have proposed
       AAL5 for use with both connection-oriented and connectionless services.

A recent document which describes these (except AAL2) with frame formats is:
"Asynchronous Transfer Mode (ATM) and ATM Adaptation Layer (AAL) Protocols
Generic Requirements",  Bellcore Technical Advisory, TA-NWT-001113, Issue 1,
August 1992.  This can be obtained by writing to:

    Bellcore
    Document Registrar
    445 South Street - Rm. 2J125
    P.O. Box 1910
    Morristown, NJ  07962-1910

SUBJECT:  D2)   Are ATM cells delivered in order?

    Yes.  The ATM standards specify that all ATM cells will be delivered
in order.  Any switch and adaptation equipment design must take this into
consideration.


SUBJECT:  D3)   What do people mean by the term "traffic shaping"?

        Here is an explicit definition of traffic shaping followed by brief
tutorial.  Note that a variety of techniques have been investigated to
implement traffic shaping.  Reference the literature for keywords such as
"leaky bucket", "congestion", "rate control", and "policing".

Definition:
Traffic shaping is forcing your traffic to conform to a certain
specified behavior.  Usually the specified behavior is a worst case or a
worst case plus average case (i.e., at worst, this application will generate
100 Mbits/s of data for a maximum burst of 2 seconds and its average over
any 10 second interval will be no more than 50 Mbit/s).

Of course, understand that the specified behavior may closely match the
way the traffic was going to behave anyway.  But by knowing precisely
how the traffic is going to behave, it is possible to allocate resources
inside the network such that guarantees about availability of bandwidth
and maximum delays can be given.


Brief Tutorial:
Assume some switches connected together which are carrying traffic.
The problem to actually deliver the grade of service that has been promised,
and that people are paying good money for. This requires some kind of resource
management strategy, since congestion will be by far the greatest factor
in data loss. You also need to charge enough to cover you costs and make a
profit, but in such a way that you attract customers. There are a number
of parameters and functions that need to be considered:

PARAMETERS
----------
There are lots of traffic parameters that have been proposed for resource
management. The more important ones are:
    mean bitrate
    peak bitrate
    variance of bitrate
    burst length
    burst frequency
    cell-loss rate
    cell-loss priority
    etc. etc.

These parameters exist in three forms:
    (a) actual
    (b) measured, or estimated
    (c) declared (by the customer)

FUNCTIONS
---------
(a) Acceptance Function
-----------------------
Each switch has the option of accepting a virtual circuit request based on
the declared traffic parameters as given by the customer. Acceptance is
given if the resulting traffic mix will not cause the switch to not
achieve its quality of service goals.

The acceptance process is gone through by every switch in a virtual
circuit. If a downstream switch refuses to accept a connection, an
alternate route might be tried.

(b) Policing Function
---------------------
Given that a switch at the edge of the network has accepted a virtual
circuit request, it has to make sure the customer equipment keeps its
promises. The policing function in some way estimates the the parameters
of the incoming traffic and takes some action if they measure traffic
exceeding agreed parameters. This action could be to drop the cells, mark
them as being low cell-loss priority, etc.

(c) Charging Function
---------------------
The function most ignored by traffic researchers, but perhaps the most
important for the success of any service! Basically, this function
computes a charge from the estimated and agreed traffic parameters.

(d) Traffic Shaping Function
----------------------------
Traffic shaping is something that happens in the customer premise equipment.
If the Policing function is the policeman, and the charging function is the
judge, then the traffic shaper is the lawyer. The traffic shaper uses
information about the policing and charging functions in order to change
the traffic characteristics of the customer's stream to get the lowest
charge or the smallest cell-loss, etc.

For example, an IP router attached to an ATM network might delay some
cells slightly in order to reduce the peak rate and rate variance without
affecting throughput. An MPEG codec that was operating in a situation
where delay wasn't a problem might operate in a CBR mode.

Game theory buffs will note that the charging function and the shaping
function form a 2-player game.



SUBJECT:  D4)   What is happening with signalling standards for ATM?

        The Signaling Sub-Working Group of the ATM Forum's Technical
Committee has completed its implementation agreement on signaling at the
ATM UNI.  The protocol is based on Q93B with extensions
to support point-to-multipoint connections.  Agreements on addressing specify
the use of GOSIP-style NSAPs for the (SNPA) address of an ATM end-point
at the Private UNI, and the use of either or both GOSIP-style NSAPs and/or
E.164 addresses at the Public UNI.  The agreements have been documented
as part of an updated (3.0) UNI specification.

Additionally, the ANSI T1S1 as well as the CCITT sudygroup XI are concerned
with ATM signalling.


SUBJECT:  D5)   What is VPI and VCI?

        ATM is a connection orientated protocol and as such there is a
connection identifier in every cell header which explicitly associates a cell
with a given virtual channel on a physical link.  The connection identifier
consists of two sub-fields, the Virtual Channel Identifier (VCI) and the
Virtual Path Identifier (VPI).  Together they are used in multiplexing,
demultiplexing and switching a cell through the network.  VCIs and VPIs are
not addresses.  They are explicitly assigned at each segment (link between ATM
nodes) of a connection when a connection is established, and remain for the
duration of the connection.  Using the VCI/VPI the ATM layer can
asynchronously interleave (multiplex) cells from multiple connections.


SUBJECT:  D6)   Why both VPI *and* VCI?

        The Virtual Path concept originated with concerns over the cost of
controlling BISDN networks.  The idea was to group connections
sharing common paths through the network into identifiable units (the Paths).
Network management actions would then be applied to the smaller number of
groups of connections (paths) instead of a larger number of individual
connections (VCI).  Management here including call setup, routing, failure
management, bandwidth allocation etc.  For example, use of Virtual Paths in
an ATM network reduces the load on the control mechanisms because the function
needed to set up a path through the network are performed only once for all
subsequent Virtual Channels using that path.  Changing the trunk mapping
of a single Virtual Path can effect a route change for every Virtual Channel
using that path.

Now the basic operation of an ATM switch will be the same, no matter if it is
handling a virtual path or virtual circuit.  The switch must identify on
the basis of the incomming cell's VPI, VCI, or both, which output port to
forward a cell received on a given input port.  It must also determine what
the new values the VPI/VCI are on this output link, substituting these
new values in the cell.


SUBJECT:  D7)   How come an ATM cell is 53 bytes anyway?

        ATM cells are standardized at 53 bytes because it seemed like a
good idea at the time!  As it turns out, during the standardization process
a conflict arose within the CCITT as to the payload size within an ATM
cell.  The US wanted 64 byte payloads because it was felt optimal for
US networks.  The Europeans and Japanese wanted 32 payloads because it was
optimal for them.  In the end 48 bytes was chosen as a compromise.  So
48 bytes payload plus 5 bytes header is 53 bytes total.

The two positions were not chosen for similar applications however.
US proposed 64 bytes taking into consideration bandwidth utilization for
data networks and efficient memory transfer (length of payload should be
a power of 2 or at least a multiple of 4). 64 bytes fit both requirements.

Europe proposed 32 bytes taking voice applications into consideration. At
cell sizes >= 152, there is a talker echo problem. Cell sizes between 32-152
result in listener echo. Cell sizes <= 32 overcome both problems, under ideal
conditions.

CCITT chose 48 bytes as a compromise. As far as the header goes, 10% of
payload was perceived as an upper bound on the acceptable overhead, so 5 bytes
was chosen.


SUBJECT:  D8)   How does AAL5 work?

        Here is is a very simplified view of AAL5 and AALs in general.
AAL5 is a mechanism for segmentation and reassembly of packets.  That is,
it is a rulebook which sender and receiver agree upon for taking a long
packet and dividing it up into cells.  The sender's job is to segment the
packet and build the set of cells to be sent.  The receiver's job is to
verify that the packet has been received intact without errors and to
put it back together again.

In AAL5, a packet is segmented as follows:

   - The packet is divided up into 48 byte chunks -- each chunk is
placed into a separate cell (carried on the same VCI)

   - If the last chunk is from 1 to 40 bytes, then the last eight
bytes in that cell are filled with the AAL5 trailer (2 bytes reserved,
2 bytes of packet length, and 4 bytes of CRC).  (If the last chunk is
less than 40 bytes, then padding is added to place the trailer at the
end of the cell.)

   - If the last chunk is from 41 to 48 bytes, then that chunk is
placed into a cell and an additional cell is added.  In that additional
cell, the last eight bytes are used for the AAL5 trailer and the rest
is padding.

   - The payload type in the last cell (i.e., wherever the AAL5 trailer
is) is marked to indicate that this is the last cell in a packet.  (The
receiver may assume that the next cell received on that VCI is the
beginning of a new packet.)

There are two problems that can happen during transit.  First, a
cell could be lost.  In that case, the receiver can detect the problem
either because the length does not correspond with the number of cells
received, or because the CRC does not match what is calculated.  Second,
a bit error can occur within the payload.  Since cells do not have any
explicit error correction/detection mechanism, this cannot be detected
except through the CRC mismatch.

Note that it is up to higher layer protocols to deal with lost and
corrupted packets.  Most people assume that a corrupted packet will be
handled by discarding it and treating it as if it were lost.



SUBJECT:  D9)   What are the diffferences between Q.93B and Q.931?

        Essentially, Q.93B is an enhanced signalling protocol for call
control at the Broadband-ISDN user-network interface, using the ATM
transfer mode.  The most important difference is that unlike Q.931
which manages fixed bandwidth circuit switched channels, Q.93B has
to manage variable bandwidth virtual channels.  So, it has to deal
with new parameters such as ATM cell rate, AAL parameters (for
layer 2), broadband bearer capability, etc.  In addition, the ATM
Forum has defined new functionality such as point-to-multipoint
calls.  The CCITT Recommendation will specify interworking
procedures for narrowband ISDN.



-----------------------------------------------------------------------------
TOPIC:     E)   TOPIC: ATM VS. XYZ TECHNOLOGY
-----------------------------------------------------------------------------
SUBJECT:  E1)   How does ATM differ from SMDS?

    SMDS is the Switched Multimedia Data Service, a service offering
interface from Bellcore.  SMDS provides a datagram service, where a packet has
about a 40-octet header plus up to 9188 octets of data. The packets themselves
may or may not be transported within the network on top of a connection-
oriented ATM service.  SMDS uses E.164 (ISDN) addresses.  Therefore SMDS is
a connectionless packet switched *service*, not a cell-relay service.

HOWEVER, the SMDS Subscriber Network Interface is currently defined to use
IEEE 802.6 Distributed Queue Dual Bus (DQDB) access across the SMDS
user-network interface.  DQDB itself *is* a form of cell relay.  The lower
layers of SMDS fragment the packets into cells with a 5-octet header and
48-octet payload.  The payload itself has a 2-octet header, 44-octets of data,
plus a 2-octet trailer.  An SMDS cell therefore is nearly identical in form
to an AAL3/4 cell.

Note that while DQDB is used as the aaccess protocol, either DQDB or AAL3/4
may be used for the switch-to-switch interface.

-----------------------------------------------------------------------------
TOPIC:     F) + TOPIC: FREELY AVAILABLE REFERENCE IMPLEMENTATIONS
-----------------------------------------------------------------------------
SUBJECT:  F1) + What and where is VINCE?

         Vince has now on record as the first "publicaly available" software
source code in the ATM technology area.  This work was carried out by the
Research Networks section of the Center for Computational Science at the
Naval Research Laboratory, with support from the Advanced Research Projects
Agency and NAVSEA.  In the Grand Internet Tradition, these fine folks have
contributed their efforts to the community in support of further research.

         The following is from the October 14, 1993 posting announcing the
availability of VINCE....

VINCE RELEASE 0.5 ALPHA

Vince, the Vendor Independent Network Control Entity, is
publicly available (in source code form) as an
alpha release. Its primary function is to perform ATM
signalling and VC management tasks. It currently includes
a hardware module that allows it to run on Fore ASX-100(tm)
switches.  Other hardware modules are under development.

Vince consists of a core which provides basic ATM network
semantics, and modules to perform specific functions. Modules
included in this release are:

  spans  - module which intereroperates signalling and routing
           with Fore Systems ASX switch and various host interfaces.
           SPANS is (tm) Fore Systems, Inc.

  q93b   - an implementation of signalling as specified in the ATM
           Forum UNI 3.0 document.  The vince core includes sscop
           and aal5 in its protocol library.

  sim    - a software ATM switch or host that can be used to test
           signalling and routing implementations without ATM
           hardware.

  sroute - an address independent VC routing module.

The Vince distribution also contains a driver that uses spans for
signalling and supports the Fore Systems SBA-100 under SunOS(tm).

Work has already begun on a kernel version of Vince, which will
allow ATM Forum UNI signalling for hosts.  Also in development
are SNMP/ILMI support, interdomain routing, and support for other
switches.

The intent is to provide a redistributable framework which
allows for code sharing among ATM protocol developers.

Vince and its architecture document are available for
anonymous ftp at hsdndev.harvard.edu:pub/mankin
           vince_0.5a.tar.Z.

A mailing list for Vince developers and users can be joined
by sending mail to [e-mail].



-----------------------------------------------------------------------------
CONTRIBUTORS

This FAQ is a collective work which has been compiled by and is maintained
by Carl Symborski.  The information contained herein has been gathered from
a variety of sources.  Most derived from a consensus of postings on the
cell-relay group.  The following individuals have provided direct
contributions to this FAQ, either by posting to the cell-relay list or
by private EMail coorespondance.  If you would like to claim responsibility
for a particular item, please let me know.

Kingston Duffie, [e-mail]
A. Gavras, [e-mail]
Rajeev Gupta, [e-mail]
Matthew Maa, [e-mail]
Craig Partridge, [e-mail]
Allen Robel, [e-mail]
Lee D. Rothstein, [e-mail]
Carl Symborski, [e-mail]
Mark Williams, [e-mail]

------ END OF FAQ -------